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The  hardware  to  produce  reasonably  fast  and  high- 
quality  computer  graphics  on  relatively  inexpensive  286-  and 
386-based  personal  computers  is  currently  available.   The 
main  disadvantage  with  this  hardware  is  that  its  price  is 
well  beyond  what  the  average  user  and  potential  researcher 
or  educational  facility  can  afford.   However,  this  problem 
can  be  alleviated  by  simulating  this  hardware  through  the 
use  of  sophisticated  software. 

This  research  attempts  to  define  a  model  for  producing 
fast  and  simple  three-dimensional  high-resolution  object- 
oriented  graphics  on  personal  computers.   This  involves  the 
efficient  storage  and  manipulation  of  a  graphics  environment 
and  graphics  database.   This  graphics  database  allows  the 
real-time  definition  and  modification  of  graphics  data. 


The  storage  of  graphics  information  can  be  achieved 
through  a  complex  set  of  graphics  data  structures  providing 
the  status  of  the  graphics  environment,  storage  of  graphics 
primitives  and  object  definitions,  and  maintenance  of  an 
active  display  list  (i.e.,  organization  of  objects  on  the 
screen) .   This  data  storage  is  transparent  to  the  user  when 
implemented. 

The  other  area  which  is  addressed  is  the  process  of 
manipulation  and  display  of  graphical  data.   A  number  of 
algorithms  are  introduced  which  make  these  processes  useful 
and  fast  on  PCs.   In  addition,  methods  for  handling  both 
hierarchical  and  geometrical  data  organizations  are 
discussed. 

This  model,  when  implemented,  provides  a  sophisticated 
low-cost,  high-speed,  three-dimensional  graphics  environment 
for  the  PC.   Its  low  overhead  and  fast  processing  provide 
the  average  user  with  a  useful  package  which  can  be  used  on 
existing  or  new  MS-DOS-based  equipment. 


INTRODUCTION 


Overview 


"Although  the  public  is  mostly  unaware  of  the  computing 
component,  computer  graphics  are,  perhaps,  the  primary 
exposure  that  the  lay  public  has  to  computing.   This  once 
mysterious,  innovative  theory  now  serves  multiple  purposes 
with  powerful  social  impact.   It  touches  many  parts  of  our 
lives — from  watching  scrubbing  bubbles  television 
commercials,  to  providing  X-ray  views  of  soft  tissue  for 
doctors,  to  viewing  pictures  of  distant  worlds  transmitted 
by  space  probes [KOC89] . " 

The  last  four  years  have  brought  great  technological 
advances  in  personal  computer  hardware,  specifically  in  the 
area  of  computer  graphics.   These  advances  have  allowed  the 
PC  to  be  used  for  computer  graphics  research  and 
applications  by  a  much  larger  group  of  users  than  ever 
before.   Continued  advances  promise  to  expand  that  audience 
to  an  even  greater  degree. 

The  PC  with  graphics  capability  has  come  into  wide 
usage  in  Computer  Aided  Design  and  Manufacturing  (CAD/CAM) 
and  there  are  approximately  twice  as  many  PC  workstations 
being  used  as  there  are  conventional  workstations .   The  PC 
is  finding  acceptance  by  scientists  and  engineers  of  all 


disciplines  including  but  not  limited  to  process  control 
applications,  lab  instrumentation,  business  graphics  and 
image  processing[MAC87 ] . 

Before  now  PCs  were  not  used  extensively  in  three- 
dimensional  (3-D)  computer  graphics  for  three  basic 
reasons [MAC87 ] :   1)   poor  response  time  (processing  speed), 
2)   low-resolution  controllers  and  displays,  and   3)   lack 
of  quality  standard  3-D  graphics  software. 

The  problem  of  processing  speed  has  been  addressed  by 
the  latest  PC's,  such  as  the  Apple  Macintosh  Ilex,  the  IBM 
Personal  System/2,  and  a  plethora  of  PC-AT  class  machines  in 
the  12-  to  33-MHZ  speed  range.   These  systems  have  high 
speed  CPU's  (such  as  the  80286)  and  are  capable  of  much 
faster  graphics.   It  is  these  and  the  next  generation  of  32- 
bit  processors  (such  as  the  80386  and  the  68020)  that  allow 
the  use  of  PCs  for  serious  graphics  research  and 
applications  (i.e.,  three-dimensional  algorithms  and  the 
like) [GUP87]. 

Display  or  graphics  controllers  have  progressed  to 
a  stage  which  allows  them  to  be  useful  in  this  area. 
Current  controllers  can  be  divided  into  two  groups  based  on 
capabilities  and  compatibilities.  The  first  group  is  those 
which  are  based  upon  the  Video  Graphics  Array  (VGA)  standard 
developed  by  IBM  (and  the  Super  VGA)  and  have  no  independent 
graphics  processor  (see  figure  1.1).   The  second  group  of 
controllers  generally  are  not  based  on  any  particular 
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standard,  have  their  own  graphics  coprocessor,  and  usually 
have  some  sort  of  3-D  engine  or  capabilities  built  in. 

VGA  was  introduced  in  mid  1987  and  was  quickly  accepted 
as  a  future  standard  by  the  video  board  industry.   The  VGA 
board  offered  several  enhancements  to  the  boards  available 
at  that  time.   These  include  higher  resolution  (640  by  480 
pixel  resolution  in  16  colors)  and  crisper,  clearer  text  and 
graphics. 

As  VGA  became  more  widely  accepted,  vendors  sought  to 
give  the  user  more  capabilities  than  IBM  and  included  higher 
resolutions.   Resolutions  of  800  by  600  and  1024  by  768 
pixels  in  256  and  16  colors,  respectively,  began  to  appear. 
These  boards  obtain  the  higher  resolutions  by  simply  adding 
more  video  memory  (up  to  512k) [DOU89] . 

These  boards  are  characterized  by  a  16-bit  data  bus  and 
graphics  functions  using  chips  such  as  the  TI  34010[PON89] . 
Performance  level  for  these  boards  is  in  the  2.5  million  to 
10  million  pixel  per  second  range.   Prices  for  these  boards 
vary  anywhere  from  $400  to  $2000[ JAM87] . 

The  second  set  of  controllers,  termed  "independent 
graphics  pipelines"  or  "3-D  graphics  engines"  are  developed 
and  manufactured  by  several  vendors,  such  as  Matrox,  Metheus 
Corporation,  and  Nth  Graphics [ DRE89 ] .   The  main  goal  of 
these  boards  is  to  provide  high  speed  and  interaction 
through  the  use  of  a  dedicated  graphics  processor. 

"Recognizing  that  high  interactivity  was  vital  to  a 
visual  user  interface  and  that  maintaining  a  display  with 


higher  resolution  and  realism  required  more  processing 
capability  than  was  available  from  the  CPU,  several 
manufacturers  designed  and  built  PCs  with  dedicated 
graphics  processing [ GUP87] . " 

Providing  a  dedicated  graphics  processor  has  two 
benefits:   1)  faster  screen  management,  and  2)  achievement 
of  a  small  amount  of  parallelism[GUP87] . 

Screen  resolutions  for  these  boards  range  as  high  as 
1280  by  1024  pixels  with  60  Hz  non-interlaced  refresh  rates. 
In  addition,  there  is  a  choice  of  256  colors  displayed  from 
a  palette  of  up  to  16.8  million  colors. 

However,  the  key  for  these  boards  is  speed.  "You  can 
never  have  enough  speed[WES89 ] . "   The  trick  is  to  find  the 
best  combination  of  drawing  speed  with  color  and  screen 
resolution  to  keep  ahead  of  the  competition,  yet  remain 
affordable. 

One  method  of  producing  speed  in  these  boards  is  to  use 
"display  list  processing. [DRE89] "   This  is  a  means  of 
depicting  a  drawing  as  a  list  of  graphic  primitives  (i.e. 
vectors,  etc.)  that  comprise  the  drawing  (see  figure  1.2). 
This  means  that  the  list  of  graphic  vectors  in  memory  (on 
the  PC)  is  the  drawing  rendered  on  the  screen.   This  display 
list  is  processed  by  the  display  processor  during  each 
refresh  cycle  of  the  screen  and  its  contents  are  displayed. 
Changing  the  screen  requires  that  the  display  list  be 
changed  prior  to  or  between  refresh  cycles  so  that  the  cycle 
is  not  interrupted . 
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Processing  proceeds  in  two  basic  steps:  1)  clipping  and 
transforming  the  vectors  as  the  active  drawing  is  modified, 
and  2)  rendering  the  results  on  the  screen.   While  each  step 
is  handled  separately,  both  are  integrated  into  a  single 
graphics  pipeline.   Each  graphics  step  is  performed  by  a 
dedicated  chip  or  suite  of  chips,  such  as  the  Intel  N10 
chip,  optimized  for  the  job[BR089]  [NEF89]. 

Speed  can  be  further  improved  by  keeping  a  copy  of  the 
display  list  in  memory  on  the  board  instead  of  on  the  PC's 
hard  disk  or  RAM.   The  PC's  list  gets  updated  from  time  to 
time  or  only  after  the  drawing  is  complete. 

This  class  of  boards  may  use  anywhere  from  24  to  64 
bits  per  pixel[RAS89] .   Performance  levels  on  these  boards 
is  up  to  the  20  million  pixels  per  second  range.   The  major 
drawback  is  the  fact  that  they  cost  between  $3000  and 
$10,000. 

The  ability  to  work  well  on  AT  class  machines  is  a 
major  advantage  of  these  boards.   A  PC  AT  with  a  high-end 
3-D  board  runs  at  10  times  the  speed  of  a  386-class  machine, 
while  retaining  a  wider  choice  of  applications.   The  result 
is  a  DOS-based  graphics  workstation  costing  $5500  to  $12,500 
that  performs  3-D  wire-frame  and  shading  functions  at  speeds 
found  only  in  $50,000  to  $70,000  workstations. 

In  summary,  the  hardware  to  produce  reasonably  fast  and 
high-quality,  three-dimensional  computer  graphics  on  286- 
and  386-based  PCs  is  now  available.   The  main  disadvantage 
with  this  hardware  is  that  its  price  is  well  beyond  what  the 
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average  user  and  potential  researcher  or  educational 
facility  can  afford.   However,  this  problem  can  be 
alleviated  by  simulating  this  hardware  through  the  use  of 
sophisticated  software.   This  is,  in  part,  the  secondary 
goal  of  this  research.   The  third  and  final  problem  is  that 
of  software. 

Descriptions  of  Proposed  Graphics  Standards 
Three-dimensional  computer  graphics  software  remains 
somewhat  in  the  infant  stage  in  both  design  and  usage.   Most 
people  usually  end  up  re-developing  known  procedures  when 
they  write  graphics  applications,  especially  working  on  a 
PC.   There  are,  however,  several  standards  and  proposed 
standards  for  graphics  software.  Two  to  be  considered  in 
greater  detail  are  the  Graphical  Kernel  System  3-D  (GKS  3-D) 
and  the  Programmers  Hierarchical  Interactive  Graphics  System 
(PHIGS) [BON86] .  These  are  the  most  actively  used  and 
discussed  software  systems  in  the  computer  graphics 
industry. 

GKS  3-D 

GKS  3-D  is  a  proposed  three-dimensional  superset  of  the 
current  GKS  standard.   It  is  designed  to  provide  a  basic  set 
of  3-D  functions  with  provisions  for  incorporating  hidden 
line/hidden  surface  removal.   It  is  upwardly  compatible  with 
GKS  so  that  GKS  programs  can  run  unmodified  in  the  GKS  3-D 
environment.   GKS  3-D  provides  a  full  set  of  viewing 
operations  that  can  support  not  only  the  widely  known 


synthetic  camera  model  but  also  any  special  viewing  model 
tailored  to  the  application[PUK86] . 

GKS  3-D  is  entirely  a  3-D  system.   This  means  that  all 
geometric  operations  within  GKS  3-D  occur  in  three 
dimensions.   At  the  heart  of  the  GKS  3-D  model  is  the 
concept  of  a  single  transformation  pipeline  that  supports 
only  3-D  constructs  and  treats  two-dimensional  (2-D) 
operations  as  shortened  3-D  operations.   Data  stored  in  GKS 
3-D,  such  as  segments,  are  kept  in  3-D  form.   All  data  which 
GKS  3-D  uses  is  three  dimensional  even  though  its  original 
specification  may  have  been  two  dimensional [PUK86 ] . 

GKS  3-D  extends  each  GKS  primitive  to  three  dimensions. 
The  GKS  3-D  primitives  include  the  following [ PUK86 ] : 
POLYLINE  —  a  sequence  of  straight  line  segments  connecting 
a  series  of  3-D  points;  POLYMARKER  —  a  symbol  referenced  to 
one  or  more  3-D  points;  TEXT  —  a  string  of  characters  in  a 
specified  place;  FILL_AREA  —  a  planar  polygonal  region  that 
may  be  filled  with  a  solid  color  or  pattern,  or 
crosshatched;  FILL_AREA_SET  —  one  or  more  planar  polygonal 
regions,  each  of  which  has  edges;   CELL_ARRAY  —   a 
parallelogram  composed  of  individual  color  cells;  and 
GENERALIZED_DRAWING_PRIMITIVE  —  for  accessing  non-standard 
3-D  graphical  output  capabilities . 

While  GKS  3-D  defines  both  a  2-D  and  3-D  form  of  each 
output  function,  it  defines  only  one  form  of  each  output 
primitive.   So  2-D  functions  generate  3-D  primitives  with  a 
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Z  value  of  zero.   The  geometry  of  each  primitive  is 
contained  entirely  within  the  primitive [ PUK86 ] . 

GKS  3-D  supports  four  types  of  transformations: 
normalization,  segment  and  insert,  viewing,  and  workstation. 
The  viewing  transformation  is  unique  to  GKS  3-D,  while  the 
other  three  are  supported  in  GKS  in  2-D  form.   Together 
these  transformations  form  the  GKS  3-D  transformation 
pipeline [PUK86] . 

GKS  3-D  is  designed  to  provide  a  strict  extension  of 
GKS  to  support  3-D  functionality.   It  allows  existing  GKS 
programs  to  operate  in  a  3-D  environment  and  also  allows 
existing  GKS  code  to  be  included  in  3-D  applications [PUK86 ] . 

PHIGS 

PHIGS  is  the  other  proposed  standard  for  3-D  computer 
graphics.   PHIGS  is  useful  for  applications  that  manipulate 
complex  displays  of  2-D  or  3-D  data  in  a  highly  interactive 
environment.   Its  major  advantage  is  in  its  hierarchical 
data  organization  and  flexible  editing  capabilities. 

The  primary  purpose  of  PHIGS  is  to  free  applications 
programmers  of  the  burden  of  developing  systems  that 
effectively  and  rapidly  display  and  manipulate  their 
application  models.   It,  perhaps,  could  be  considered  the 
"interaction  toolset  for  graphical  model  building  and 
manipulation [SHU8 6] . " 

"The  key  features  of  PHIGS  are  its  ability  to 
efficiently  describe  the  application  model  in  the  graphics 
system  and  to  rapidly  update  the  graphics  model  and 
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corresponding  rendering  as  the  application  model  changes. 
The  organization,  content,  and  modif iability  of  the  graphics 
data  are  the  key  aspects  that  make  PHIGS  a  model 
manipulator's  graphical  toolset [ SHU86 ]. " 

PHIGS  has  a  set  of  primitives  similar  to  those  of  GKS 
3-D,  including  a  very  powerful  hierarchical  graphical  data 
structure  known  as  a  STRUCTURE.   This  hierarchical  data 
organization  is  commonly  used  in  many  applications  and  can 
easily  be  mapped  onto  and  from  other  data 
organizations [ SHU86 ] . 

Major  Differences  Between  PHIGS  and  GKS  3-D 

Some  of  the  major  differences  between  PHIGS  and  GKS  3-D 
are[SCH86]:  1)  GKS's  data  structure,  the  segment,  is 
restricted  to  a  single  level  and  is  used  to  represent 
information  about  a  graphics  image  rather  than  information 
about  a  graphics  model  (such  as  in  PHIGS).   In  addition,  the 
segment  stores  normalized  data  while  the  PHIGS  structures 
are  defined  in  modeling  coordinates.   2)  Once  a  GKS  segment 
is  created  its  contents  cannot  be  modified.   Only  aspects 
affecting  the  whole  segment  such  as  visibility  or  segment 
transformation  can  be  changed.   PHIGS  allows  any  part  of  a 
structure  to  be  modified  at  any  time.   3)  GKS  binds  or 
associates  attributes ( i. e. ,  line  color,  style,  etc.)  to 
primitives  when  they  are  created  and  before  they  are  stored 
in  the  graphics  data  structure.   Modifying  primitive 
attributes  after  a  segment  is  created  requires  deleting  the 
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segment  and  recreating  it  with  different  attributes.   In 
PHIGS,  output  primitive  elements  become  output  primitives 
only  when  a  structure  is  traversed  for  display.   This  is 
also  the  point  at  which  attribute  structure  elements  are 
bound  to  output  primitives.   The  traversal-time  binding  of 
attributes  allows  flexible,  easy  modification  of  graphics 
data.   4)  GKS  provides  a  limited  modeling  transformation, 
called  a  normalization  transformation,   that   is   applied 
once  to  a  given  set  of  data.   PHIGS  allows  multiple, 
cumulative  modeling  transformations  to  be  applied  in 
modeling  space  at  traversal  time. 

GKS  3-D  and  PHIGS  differ  primarily  in  these  areas  only. 
In  fact,  PHIGS  actually,  in  terms  of  primitives,  is  a 
superset  of  GKS  3-D. 

The  current  implementations  of  GKS  available  for  the  PC 
are  the  2-D  versions,  and  none  of  the  implementations 
address  the  new  equipment  in  the  PC  realm  other  than  VGA 
(640  by  480  in  16  colors).   There  is  an  implementation  of 
PHIGS  for  the  286-  and  386-based  PCs[CGA89].   However, 
because  of  its  high  cost  and  complexity,  it  is  not  useful 
for  the  average  user.   In  addition,  it  only  supports  the 
standard  VGA  mode . 

Proposed  Research 
There  exists  a  need  for  a  new  graphics  software 
standard[PUK88] ,  one  which  will  be  better  oriented  for  the 
PC  environment.   It  should  have  an  object-oriented  data 
structure  (like  PHIGS)  that  allows  the  programmer  to  develop 
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a  graphics  model.   It  should  be  device  independent  so  as  to 
allow  the  user  to  take  advantage  of  new  hardware  for  the  PC. 
And  finally,  it  should  use  a  simpler  3-D  graphics  viewing 
pipeline  which  allows  the  programmer  to  do  everything  in 
terms  of  modeling  space. 

The  system  which  is  to  be  designed  through  this 
research  could  be  used  as  a  model  for  a  much-needed  PC 
graphics  software  standard  mentioned  above.  This  system 
would  have  some  of  the  best  features  of  both  GKS  3-D  and 
PHIGS  while  still  taking  into  account  some  of  the  PC's 
limitations,  such  as  memory  allocation  and  data  storage. 

The  system  should  be  defined  in  terms  of[BR085]   1) 
control  functions,   2)  output  primitive  functions,   3) 
attribute  setting  functions,   4)  workstation  table  setting 
functions,   5)  structure  operations,   6)  input  functions, 
7)  display  functions,   8)  transformations  functions,  and  9) 
utility  functions  (which  includes  error  condition  actions 
and  inquiry) . 

The  language  binding  for  this   system  will  be  the  C 
language  although  it  can  easily  be  extended  to  include  other 
languages  such  as  Pascal,  Modula-2,  and  Ada.   The  graphics 
software   and  display  list  processing,   because  of  C's 
low-level  functionality,  will  be  most  effective  and  faster 
in  C.   Since  C  is  a  high-level  language  and  is  widely  used 
in  academic  environments,  it  is  a  natural  selection  for  the 
user  interface.  In  addition,  many  graphics  algorithms  are 
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currently  defined  in  terms  of  C-like  languages  and  therefore 
would  increase  the  system's  versatility  and  friendliness. 

The  minimum  hardware  required  for  such  a  system  is  an 
Intel  80286-based  10  MHz  system.   The  minimum  graphics 
hardware  should  be  IBM's  VGA,  which  has  a  resolution  of  at 
least  640  by  480  pixels  (although  resolutions  of  800  by  600 
or  1024  by  768  are  preferred) .   Additionally,  a  math 
coprocessor  will  enhance  the  system.   Graphical  input  can  be 
obtained  through  the  use  of  a  pointing  device.   This  will 
allow  a  wide  variety  of  applications,  including  but  not 
limited  to  algorithm  research,  computer  vision,  image 
processing,  robotics,  user  interface  design,  and  education. 
Total  cost  for  the  system  is  in  the  $2500  to  $3500  range. 

The  primary  aim  of  this  research  is  to  develop  a  model 
of  a  user-interface  for  a  low-cost  high-resolution  graphics 
system  on  which  the  average  user  can  easily  produce  object- 
oriented   3-D  graphics.   The  model  is  targeted  for  users 
such  as  universities  where  funds  are  limited  and  there  is 
already  existing  PC  equipment  which  could  be  utilized  for 
this  type  of  research.   "Producing  interesting  pictures  of 
objects  with  expensive  equipment  is  easy,  but  producing  the 
same  quality  imagery  with  inexpensive  equipment  is 
interesting [ STA89] . "   This  model,  when  implemented, 
simulates  the  operations  which  are  performed  by  dedicated 
graphics  processors  on  more  expensive  systems  and  provide  a 
simple  and  useful  three-dimensional  graphics  environment. 
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The  purpose  of  this  research  is  threefold:   1)  to 
determine  the  problems  that  need  to  be  addressed  by  a  3-D 
software  system  for  the  PC  environment,   2)  to  design  (and 
implement  a  subset  of)  a  3-D  graphics  system  which  addresses 
these  problems,  and  3)  to  determine  the  feasibility  of 
effectively  using  this  system  in  a  PC  environment  for  3-D 
graphics  applications  and  research. 


A  SIMPLE  SOFTWARE  ENVIRONMENT  FOR  3-D  GRAPHICS 

PHIGS-Like-Graphics  (PLG)  is  a  model  for  a  software 
environment  for  3-D  graphics  on  personal  computers  which 
consists  of  a  robust  set  of  functions  loosely  based  on  the 
PHIGS  standard.   The  hierarchical  organization  of  data, 
storage  of  data,  methods  of  local  and  global 
transformations,  and  object-  oriented  approach  [BR085]  are 
all  necessary  for  the  system  to  be  useful,  yet  remain 
simple. 

The  ultimate  goal  of  PLG  is  to  produce  a  picture  on  the 
screen.   In  PLG,  as  in  PHIGS,  objects  are  defined  by  a 
sequence  of  structure  elements  which  includes  output 
primitives,  attributes,  transformations,  and  instances  of 
other  objects.   Since  views  are  nothing  more  than  groups  of 
objects,   the  workstation  or  screen  is  constructed  from  one 
or  more  views . 

Any  graphics  system,  such  as  PLG,  must  possess  certain 
characteristics  similar  to  the  ones  discussed  in  the 
following  paragraphs.   Pictures  built  from  geometric  models 
(organized  for  use  of  relative  positioning  and  movement) 
have  a  clearly  defined  structure.   This  structure  could 
easily  be  seen  in  repeated  use  of  symbols,  connections,  or 
overall  organization  of  a  complex  image.   An  example  of  this 
would  be  a  robot  arm  where  the  movement  of  parts  of  the  arm 
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are  dependent  on  the  position  of  the  parts  to  which  they  are 
connected  (see  figure  2.1).   If  the  object's  structure  is 
not  clear,  its  underlying  data  organization  should  be 
understood  by  the  application  (hierarchical  organization  — 
for  ease  of  picture  construction) .   For  example,  take  an 
image  of  a  table  constructed  of  various  parts  (i.e.,  table 
top  and  legs),  some  of  which  may  be  the  same  object  (a  leg) 
positioned  differently  (see  figure  2.2).   The  software 
should  support  both  cases  by  separating  the  definition  of 
graphics  data  from  the  actions  required  to  display  them 
[BR085] . 

The  structured  definition  of  graphics  data  inherently 
reduces  repetition  and  connectivity  problems .   The  repeated 
use  of  object  components  and  relationships   between  them 
should  be  a  part  of  an  object's  definition. 

Picture  component  construction  should  also  be 
supported.   The  structured  definition  of  data  will  allow 
objects  to  share  components.   This  allows  faster  and  easier 
definition  and  modification  of  picture  descriptions .   This 
also  reduces  storage  requirements  for  graphics  data. 

There  is  a  need  for  interactivity.   Whenever  possible 
the  software  should  support  real-time  definition  and 
modification  of  graphics  data.   The  ability  to  add  or  delete 
individual  primitives  is  desirable  though  not  necessary. 

The  system  should  perform  3-D  modeling  transformations 
and  3-D  viewing  projections  (perspective  and  parallel). 
General  modeling  will  provide  the  flexibility  of  defining 
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objects  in  their  natural  coordinate  system  and  then 
positioning  them  (using  scaling,  rotation,  or  translations) 
in  some  other  coordinate  system.   There  is  no  need  for  a 
workstation  transformation  (in  the  traditional  sense)  since 
only  a  single  workstation  is  supported.   However,  if  a 
network  version  were  to  be  needed,  the  workstation 
transformation  might  be  of  some  use. 

A  good  graphics  system  should  relieve  the  applications 
programmer  of  certain  tasks.   Specifically,  it  should  manage 
the  storage  and  display  of  3-D  graphical  data.   A 
hierarchical  database  will  be  created  and  maintained  to 
relieve  the  application  of  a  large  amount  of  overhead.   It 
should  allow  the  user  to  select  any  view  of  the  data  and 
then  generate  2-D  drawings  of  3-D  objects. 

Areas  in  which  this  type  of  graphics  system  would  be 
useful  include,  but  are  not  limited  to  computer  aided 
engineering  (i.e.,  drafting,  VLSI  design,  and  finite  element 
modeling);  process  control  (i.e.,  numerical  control  data  and 
tool  path  simulation,  process  monitoring,  and  robotics); 
command  and  control  (i.e.,  defense  simulation,  weapons 
system  management,  and  traffic  control  simulation);  and 
others  such  as  molecular  modeling,  architectural  design,  and 
mapping . 

The  proposed  system  needs  to  include  the  following  nine 
groups  of  functions:   1)  control  functions,  2)  output 
primitive  functions,  3)  attribute  setting  functions, 
4)  workstation  table  setting  functions,  5)  structure 
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operations,  6)  input  functions,  7)  display  functions, 
8)  transformation  functions,  and  9)  utility  functions. 
These  functions  and  the  environment  which  they  manipulate 
are  the  key  areas  which  make  the  system  useful  [IBM85]. 

The  first  area,  control  functions,  is  used  to  modify 
system  states  and  does  not  store  or  modify  graphics  data. 
These  functions  include  initialization  and  termination 
functions  as  well  as  commands  to  control  screen  updating 
operations . 

The  output  primitives  address  the   specification  and 
creation  of   drawing  elements   (i.e.   structure  elements). 
They  have  a  3-D  form  (i.e.  an  x,  y,  and  z   coordinate)   and 
are  displayed  when  the  structure  in  which  they  are  contained 
is  encountered  during  structure  traversal .   The  output 
primitives  should  include  specifications  for  drawing  lines, 
generating  text,  creating  polygons  (hollow  or  filled),  and 
possibly  pixel  arrays,   the  latter  being  less  useful  than 
the  rest.   These  primitives  require  that  functions  to 
initialize  the  graphics  system  be  called  prior  to  their  use 
and  may  only  be  inserted  into  open  structures . 

The  attribute  functions  are  used  to  describe  the 
characteristics  of  output  primitives,  including  size,  shape, 
style,  and  color.   These  functions  should  set  environmental 
parameters  which  are  inherited  by  structure  elements .   They 
are  bound  to  the  primitives  at  creation  time  but  may  be 
changed  at  any  time.   These  attributes  are  applied  at 
traversal  time.   They  include  basic  functions  such  as  line 
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color,  interior  color  and  style  for  polygons,  and  text  size 
factors. 

The  workstation  functions  are  less  useful  in  a  PC-based 
system  such  as  this  one,  but  they  do  include  some  important 
operations.   The  ability  to  set  characteristics  for  each 
existing  view  is  a  necessity.   These  characteristics  include 
setting  viewing  projection  (parallel  or  perspective),  view 
reference  point  (the  viewer's  eye  position),  and  visibility. 

The  structure  operation  functions  allow  an  application 
program  to  manipulate  structures  and  their  contents .   These 
include  operations  to  create  (open  and  close)  a  structure, 
delete  a  structure,  edit  a  structure,  and  execute  a 
structure,  the  latter  being  useful  for  creating 
hierarchically  structured  objects. 

Input  functions  allow  the  application  to  interact  with 
the  user.   These  functions  should  support  the  major  input 
devices  used  on  PCs.   These  include  the  mouse,  the 
joystick,  and  a  general  input  device  using  the  serial  port. 

The  display  functions  are  also  a  small  but   necessary- 
set  of  functions.   These  include  the  method  for  associating 
structures  with  views.   This  allows  for  an  N  to  M 
relationship  between  views  and  structures  (i.e.  many 
structures  may  be  associated  with  multiple  views  and  vice- 
versa)  . 

Transformation  functions  fall  into  two  categories: 
modeling  and  viewing.   The  modeling  transformations  are  used 
globally  (when  applied  to  an  entire  view)  or  locally  (when 
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applied  within  a  structure) .   They  allow  the  application 
program  to  move  and  place  objects.   The  viewing 
transformations  are  used  for  setting  window  and  viewport 
limits  and  for  mapping  from  world  coordinates  to  device 
coordinates . 

Utility  functions  include  anything  which  does  not  fit 
into  the  above  categories.   They  may  include  mechanisms  for 
creation  and  manipulation  of  matrices  and  functions  which 
"query"  the  system  to  determine  information  about  its 
current  status .   This  information  is  usually  stored  in 
environmental  variables,  and  these  functions  shield  the 
environment  from  abuse  by  the  application  while  still 
allowing  access  to  the  information. 

The  above  areas  are  the  minimum  necessary  for  a  useful 
3-D  graphics  system.   The  main  objective  is  for  the  system 
to  be  robust  without  encountering  too  much  system  and 
compute  time  overhead.   The  methods  for  accomplishing  this 
are  discussed  in  the  next  two  sections.   More  specific 
information  concerning  the  functional  specifications  for 
each  area  is  contained  in  Appendix  A. 


PLG  DATA  STRUCTURE  SUPPORT 

The  development  of  a  graphics  software  environment, 
such  as  PLG,  requires  the  use  of  several  data  structures  for 
determining  the  graphics  environment's  status,  maintaining 
graphics  data  structures,  and  managing  the  display  list. 
The  key  to  graphics  data  management  is  to  develop  a  set  of 
data  structures  which  allow  us  the  storage  of  the  most  information 
in  the  least  amount  of  space,  yet  still  be  quickly 
accessible  when  it  is  needed.   It  is  important  to  calculate 
and  store  as  much  useful  data  as  possible  prior  to  the 
traversal  or  refresh  cycle  where  it  is  used.   This  can  speed 
up  the  refresh  cycle  by  a  large  factor  since  many  of  the 
calculations  required  for  projection  are  floating  point 
functions  (such  as  sine  and  cosine). 

The  data  structure  used  for  maintaining  the  graphics 
environment  has  a  fixed  size  (approximately  600  bytes),  yet 
uses  very  little  overhead.   It  contains  various  information 
about  the  graphics  environment  state  including  whether  or 
not  the  graphics  environment  has  been  initialized.   Current 
attribute  states  regarding  line  color,  polygon  interior 
style  and  color,  and  text  color  also  reside  here.   Other 
information  useful  to  the  system  encompasses  window  and 
viewport  limits  (for  the  current  view),  pointers  to  the 
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graphics  data  structures  and  the  display  list,  a  pointer  to 
the  top  of  the  transformation  state  stack,  temporary-use 
global  matrices,  pointers  to  the  current  view  and  current 
open  structure  (together  with  a  pointer  to  its  tail),  video 
configuration,  and  the  current  video  memory  page  in  use  (for 
use  in  animation  through  video  page  switching) . 

The  storage  of  graphics  data  on  the  PC  is  a  problem 
that  must  be  carefully  addressed.   A  method  must  be 
developed  which  fits  either  a  geometrical  or  hierarchical 
form.   This  method  of  storage  should  be  transparent  to  the 
user  and  still  address  problems  such  as  memory  management 
and  speed  of  access  which  are  necessary  for  a  useful 
graphics  system. 

It  is  necessary,  at  this  point,  to  clarify  the  terms 
data  structure,  graphics  data  structure,  and  STRUCTURE. 
Data  structures  are  language  level  (and  sometimes 
application-dependent)  arrangements  of  information  accessed 
by  a  program.   This  may  involve  instances  or  combinations  of 
arrays,  records,  lists,  stacks,  trees,  and/or  files.   A 
graphics  data  structure  (GDS)  is  simply  an  implementation  of 
a  data  structure  which  stores  specific  graphics  information. 
A  STRUCTURE  is  a  logical  representation  which  allows  for  the 
creation,  modification,  and  display  of  graphical  objects. 
These  consist  of  structure  elements  (primitives)  and  are 
implemented  through  the  use  of  graphical  data  structures . 

The  other  graphics  data  structures  that  are  required 
store  two  types  of  screen  update  lists .   One  list 
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(STRUCTURES_LIST)  stores  the  actual  graphics  or  picture 
information.   The  second  list  (VIEWS_LIST)  is  a  fast-access 
display  list. 

The  STRUCTURES_LIST  is  constructed  of  STRUCTURES. 
These  STRUCTURES  are  made  up  of  5  basic  primitives:  1) 
transformations,  2)  polylines,  3)  polygons,  4)  other 
STRUCTURES  (this  is  an  execute  STRUCTURE  command),  and  5) 
text.   The  STRUCTURES  are  used  to  define  objects  in 
pictures.   This  STRUCTURES_LIST  is  a  linked  list  of 
STRUCTURES  as  they  are  created  (in  chronological  order). 
The  order  is  unimportant  and  is  not  used  for  picture 
generation.   Each  node  in  the  linked  list  contains  the 
structure  number,  visibility  flag,  and  a  pointer  to  another 
linked  list  which  stores  the  actual  primitives  and 
attributes  associated  with  a  particular  STRUCTURE  (see 
figure  3.1).   This  allows  each  STRUCTURE  to  be  stored  only 
once  and  saves  memory  and  overhead  later.   This  construction 
is  similar  to  those  suggested  in  [CAH86]  and  [BR085].   All 
information  is  stored  in  world  coordinates . 

The  method  for  storing  each  STRUCTURE  required  creating 
a  variant  record  which  could  store  information  and 
attributes  about  a  particular  primitive  or  STRUCTURE  element 
(see  figure  3.2).   This  method  of  attribute  storage  is 
different  from  PHIGS  which  binds  attributes  at  traversal 
time.   This  is  important  because  it  allows  the  refresh  cycle 
(structure  traversal)  to  occur  faster  since  all  the 
necessary  information  is  immediately  available.   It  is  not, 
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however,  a  disadvantage  due  to  the  easy  methods  for 
modification  of  STRUCTURES  after  they  have  been  created.   In 
fact,  the  STRUCTURE'S  makeup  and  attributes  may  be  changed 
between  refresh  cycles  to  create  animated  effects.     This 
method  of  storage  allows  the  system  to  dynamically  allocate 
any  memory  it  needs  to  store  data  during  the  creation  of  the 
STRUCTURES  and  therefore  reguires  very  little  fixed 
overhead.   A  STRUCTURE  element  for  a  polygon,  for  example, 
contains  the  number  of  points  in  the  polygon;  line  color  for 
the  polygon;  whether  the  polygon  has  a  hollow,  solid, 
hatched,  or  patterned  interior;  the  interior  color  or 
pattern  style  of  the  polygon;  a  calculated  interior  point 
(used  as  a  seed  for  filling);  and  a  pointer  which  indicates 
the  dynamic  array  where  the  x,  y,  z  coordinates  of  the 
vertices  of  the  polygon  are  stored.   The  same  element  for  an 
execute  STRUCTURE  instruction  only  contains  the  address  of 
the  STRUCTURE  to  execute  or  process.   This  list  also  has  all 
the  information  necessary  for  refreshing  the  screen  (in 
regards  to  the  structures  themselves)  and  nothing  must  be 
recalculated  during  that  process . 

The  second  list  which  must  be  maintained  is  a  list  of 
the  active  views  (VIEWS_LIST) .   This  contains  information 
about  each  view  including  the  view  number,  and  whether  or 
not  the  view  is  currently  active  (or  visible) .   Since 
multiple  views  are  supported,  more  than  one  view  can  share 
the  same  structures.   Again,  this  allows  for  more  efficient 
storage  of  the  data. 
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The  VIEWS_LIST  contains  a  node  for  each  view  which  has 
been  defined  by  the  application.   Each  node  contains  a 
pointer  to  a  linked  list  of  STRUCTURES  and  transformations 
which  have  been  associated  with  a  particular  view.   Only 
transformations  and  execute  STRUCTURE  instructions  are 
actually  contained  in  this  list  (see  figure  3.3).   As 
previously  noted,  the  actual  address  of  the  STRUCTURE  is 
stored  so  as  to  facilitate  quicker  refresh.   The  structures 
are  redrawn  in  chronological  order.   The  order  may  be 
changed  by  setting  priorities  (in  relation  to  other 
structures).   This  requires  only  a  manipulation  of  pointers 
to  change  structure  priorities.   The  refresh  cycle  now 
requires  that  we  simply  traverse  the  VIEWS_LIST  applying  any 
transformations  encountered  and  executing  any  structures 
encountered.   The  algorithms  used  in  this  process  are 
discussed  in  the  next  section. 

Additionally,  the  VIEWS_LIST  contains  two  special 
transformation  matrices  used  by  the  system.   The  first  is 
the  view  mapping  matrix.   This  matrix  is  used  to  maintain 
window  and  viewport  for  the  view  and  to  transform  from  eye 
coordinates  to  device  coordinates  using  formulas  suggested 
in  [NEW79].   The  second  special  matrix  is  known  as  the 
viewing  matrix.   This  transformation  is  used  to  maintain  the 
user's  viewing  reference  point.   It  converts  points  from  the 
world  coordinate  system  to  the  eye  coordinate  system.   The 
algorithm  for  this  is  discussed  in  the  next  section. 
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In  summary,  the  advantages  of  this  method  of  data 
storage  are   1)  low  overhead  (each  node  only  takes  36  bytes 
of  overhead),   2)  high  speed  of  access  (all  needed 
information  is  immediately  accessible),   3)   versatile  and 
easy  modification  of  objects,  4)  dynamic  use  of  memory 
(using  extended  memory  PLG  can  store  more  than  two  million 
line  segments  on  a  PC  AT  with  eight  megabytes),  and  5)  a 
direct,  simple  method  for  archival  processing  of  images. 


PLG  ALGORITHM  SUPPORT 

A  number  of  algorithms  are  needed  to  support  a  system 
such  as  PLG.   Three  areas  are  particularly  important:  1)  the 
viewing  pipeline,   2)  transformation  application  and 
inheritance,  and   3)  the  screen  refresh  algorithm  (structure 
traversal) . 

The  viewing  pipeline  is  similar  to  ones  suggested  in 
[HEA86],  [NEW79],  and  [FOL82]  which  include  three- 
dimensional  clipping,  viewing  projection,  and  conversion  to 
device  coordinates.   In  addition,  provisions  have  been  added 
for  hidden  surface  removal,  lighting,  and  shading  models  as 
suggested  in  the  PHIGS+  [VAN87]  specification  (see  figure 
4.1). 

The  viewing  process  is  simplified  by  storing  all 
transformations  as  matrices,  as  suggested  in  [NEW79]  and 
[VAN87].   As  usual,  the  transformation  matrices  are 
concatenated  so  very  few  are  directly  applied  to  points  thus 
greatly  speeding  execution.   This  concatenation  process 
allows  global  and  local  transformations  to  be  easily  applied 
and  inherited.   The  method  for  this  will  be  discussed  below. 

The  viewing  pipeline  is  simple.   First,  any  modeling 
transformations  (local  and  global)  are  applied,  then  the 
results  are  transformed  to  viewing  coordinates.   The  viewing 
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coordinates  are  clipped  and  projected  to  the  window. 

At  this  point,  hidden  surface  elimination  and  lighting  (and 

shading)  algorithms  would  be  applied.   Then  the  coordinates 

(which  up  to  this  point  have  all  been  three-dimensional)  are 

transformed  to  a  two-dimensional  viewport  and  finally  to 

device  coordinates  for  actual  drawing. 

PROCESS  STRUCTURE 

INITIALIZE  LOCAL  STACK_COUNT 
SET  CURRENT  TO  HEAD  OF  STRUCTURE 
WHILE  MORE  STRUCTURE  TO  PROCESS  DO 
PROCESS  EACH  PRIMITIVE  IN  STRUCTURE 
CASE  TAG  OF 

CASE  1  :  TRANSFORMATION-  PUSH  V,  INCREMENT 
STACK_COUNT,  SET  V  TO  V  x  XFORM. 
CASE  2  :  POLYLINE-  EXECUTE  POLYLINE 
CASE  3  :  POLYGON-   EXECUTE  POLYGON 
CASE  4  :  EXECUTE  STRUCTURE-  CALL  PROCESS 

STRUCTURE  (RECURSIVE) 
CASE  5  :  TEXT-   EXECUTE  TEXT 
END  CASE 

GET  NEXT  PRIMITIVE 
FOR  I  =  STACK_COUNT  DOWNTO  0   DO 

POP  V.  /*  V  IS  VIEWING  TRANSFORMATION  */ 
END  PROCESS  STRUCTURE 


Process  Structure  Algorithm 
Figure  4 . 2 


The  method  for  handling  local  and  global 
transformations  is  similar  to  that  suggested  in  [BR085]  and 
[CAH86].   The  mechanism  for  implementing  this  is 
significant.   Inherited  transformations  are  handled  with  a 
stack.   Each  time  a  new  local  transformation  is  encountered 
the  previous  concatenated  viewing  matrix  is  stored  on  a 
stack  and  a  new  viewing  matrix  is  calculated  using  the  new 
local  transformation.   When  we  leave  the  level  containing 
the  local  transformation,  rather  than  recalculating  the 
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previous  viewing  matrix  by  applying  the  inverse  of  the  local 
transformation,  we  simply  pop  the  last  viewing  matrix  off 
the  stack.   This  involves  no  recalculation  and  very  little 
overhead.   This  works  for  one  or  more  local  transformations 
on  the  same  or  different  levels  (see  figure  4.2). 

Consider  the  structures  pictured  in  figure  4.3. 
Initially,  transformation  one  is  applied  to  the  polygon 
which  forms  the  table  top  to  place  it  in  its  proper 
position.   Then  structure  two  is  processed  as  part  of 
structure  one. 

The  first  thing  encountered  is  local  transformation 
two.   At  this  point  transformation  one  is  saved  on  the  stack 
and  a  new  viewing  matrix  is  created  by  concatenating 
transformation  one  and  transformation  two.   Next  the  leg  is 
drawn  using  the  new  viewing  matrix.   This  concludes 
structure  two  and  before  leaving  this  structure  the  previous 
viewing  matrix  is  restored  from  the  stack  so  that  any 
additional  primitives  at  the  level  of  transformation  one 
will  use  only  transformation  one.   This  process  would 
continue  in  the  same  manner  for  the  other  three  structures . 
This  particular  method  works  well  for  both  geometrical  and 
hierarchical  structures . 

The  last  algorithm,  the  structure  traversal  (see  figure 
4.4),  incorporates  the  two  previous  algorithms.   The  process 
begins  with  the  first  view  and  processes  each  structure 
within  that  view.   The  nodes  associated  with  each  view  in 
the  update  list  (see  figure  3.3)  consist  only  of 
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transformations  and  execute  structure  instructions.   This 
allows  faster  processing  of  these  structures.   After  the 
last  structure  is  processed  the  next  view  is  processed  and 
so  on  until  all  views  are  processed  or  refreshed. 


PROCESS  UPDATE  WORKSTATION 
INITALIZE  STACK 
CLEAR  SCREEN 

SET  CURRENT  TO  BEGINNING  OF  VIEWS  LIST 
WHILE  MORE  VIEWS  TO  PROCESS  DO 
IF  THE  VIEW  IS  VISIBLE  THEN 
INITIALIZE  VIEW  MAP 
INITIALIZE  VIEW  MATRIX 
INITIALIZE  VIEW  TRANSFORMATION 
PROCESS  EACH  NODE 

/*  PROCESSING  EACH  STRUCTURE  AND  TRANSFORMATION 

ASSOCIATED  WITH  THIS  VIEW  */ 

WHILE  MORE  NODES  TO  PROCESS  DO 
CASE  TAG  OF 

CASE  1  :  VIEW  TRANSFORMATION-  SAME  PROCESS 

AS  IN  PROCESS  STRUCTURE 
CASE  4  :  EXECUTE  STRUCTURE-   CALL  PROCESS 
STRUCTURE 
END  CASE 
GET  NEXT  NODE 
GET  NEXT  VIEW 
END  PROCESS  UPDATE  WORKSTATION 

Process  Update  Workstation  Algorithm 
Figure  4 . 4 


Note  that  this  processing  is  a  simple  linear 
processing,  even  when  nested  structures  and  local 
transformations  are  involved.   It  is  easy  to  see  that  for 
each  active  view  the  STRUCTURES  associated  with  it  are 
visited  (executed)  once  and  requires  the  same  amount  of  work 
or  processing  for  a  visit. 

When  nested  structures  and  local  transformations  are 
encountered  they  are  handled  in  a  recursive  fashion  which 
allows  ease  of  inheritance  for  hierarchical  and  geometrical 
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organizations.   This  method  of  processing  requires  much  less 
overhead,  since  it  only  uses  recursion  under  special  cases, 
and  therefore  is  much  faster. 


CONCLUSION 

Summary 
The  primary  aim  of  this  research  was  to  design  a  three- 
dimensional  graphics  model  which  is  low-cost,  more  user- 
friendly  than  PHIGS,  more  versatile  than  GKS  3-D,  yet  still 
addresses  the  constraints  of  the  PC.   This  model  allows  both 
simple  graphics  to  be  produced  along  with  complex  objects 
defined  through  the  use  of  STRUCTURES  as  in  PHIGS.   These 
STRUCTURES  are  more  versatile  than  the  segments  created  by 
GKS  3-D  and  can  easily  be  edited  and  manipulated  through  the 
use  of  scaling  ,  translation,  and  rotation  transformations. 
The  real  time  capabilities  for  updating  the  workstation  add 
a  dimension  for  dynamic  graphics  which  GKS  3-D  does  not 
have.   In  addition,  the  user-interface  for  this  model  is 
simpler  than  PHIGS  requiring  much  less  information  to  be 
supplied  by  the  user  in  order  to  be  used.   However,  the 
model  still  addresses  and  solves  some  of  the  problems  of 
memory  management  through  the  use  of  a  sophisticated  and 
efficient  method  for  storage  and  manipulation  of  graphics 
information.   It  allows  the  user  to  define  and  manipulate 
three-dimensional  objects  in  a  simple  PHIGS-like  fashion. 
This  model  identifies  a  subset  of  PHIGS-like  capabilities 
that  comfortably  work  within  the  confines  of  a  PC. 
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PLG  allows  the  programmer  to  define  objects  in  terms 
of  geometric  or  hierarchical  relationships.   In  addition,  it 
does  so  with  a  minimum  of  effort  on  the  part  of  the  user. 
This  is  because  a  three-dimensional  graphics  database  is  created  a 
maintained  by  the  PLG  environment  to  alleviate  the  user's 
need  for  extra  programming  which  is  not  related  to  the 
application.   This  greatly  simplifies  the  programmer's  work 
and  frees  him  to  concentrate  on  developing  the  application. 

Through  the  use  of  structures,  PLG  supports 
construction  and  definition  of  objects  in  terms  of  graphics 
components.   This  allows  faster  and  easier  manipulation  and 
modification  of  pictures.   The  addition  of  an  interactive 
feature,  through  the  real-time  definition  and  modification 
of  graphics  data,  allows  the  user  to  change  individual 
primitives . 

Since  PLG  is  a  single-user  system,  much  of  the  overhead 
for  maintaining  workstations  has  been  eliminated  leaving  a 
slimmed-down,  speedier  processing  pipeline.   The  use  of 
modeling  matrices  simplifies  this  processing  even  further. 
PLG  also  supports  local  and  global  transformations  for 
STRUCTURES  and  views  which  are  used  for  manipulations  of 
object  and  scenes.   These  transformations  are  also  handled 
through  the  use  of  matrices. 

PLG  addresses  the  six  ground  rules  for  graphics 
software  design  provided  by  [NEW79]  of  simplicity, 
consistency,  completeness,  robustness,  performance,  and 
economy.   PLG  meets  these  rules  as  follows: 
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1)  It  is  simple.   There  are  no  features  or  functions 
included  which  are  too  complex  for  the  application 
programmer  to  understand.   The  model  for  the  system  is  based 
on  PHIGS  which  has  been  explained  in  many  publications. 

2)  PLG  is  consistent  and  behaves  in  a  predictable 
manner.   All  functions  are  specifically  defined  and  follow  a 
consistent  pattern  to  allow  the  programmer  to  easily  build  a 
conceptual  model  of  the  graphics  system. 

3)  PLG  is  a  complete  model  in  that  it  contains  a 
reasonably  small  set  of  functions  which  can  handle  a  wide 
variety  of  applications.   This  does  not  imply 
comprehensiveness  (i.e.,  every  imaginable  graphics 
facility) . 

4)  The  model  defines  a  number  of  defaults  allowing  a 
certain  amount  of  omission,  abuse  and  mistreatment  with  a 
minimum  of  complaint  providing  a  robust  system.  It  calls  for 
termination  of  execution  only  in  extreme  circumstances. 

5)  Since  it  is  a  single-user  system,  has  a  consistent 
performance  response  for  any  user.   It  offers  no  special 
advantages  to  one  who  understands  the  system's  internal 
workings . 

6)  An  implementation  of  this  model  is  economical,  (it 
adds  only  about  15K  bytes  in  its  current  form)  and  may  be 
added  to  almost  any  application. 

PLG's  set  of  functions  is  used  to  manipulate  the 
graphics  on  the  screen  and  maintain  the  graphics 
environment.   These  functions  address  the  nine  areas 
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discussed  previously  which  include  graphics  system  control, 
output  primitives,  setting  attributes,  workstation  table 
settings,  structure  operations,  graphical  input,  display, 
transformations,  and  various  utilities.   They  work  with  any 
currently  existing  and  future  MS-DOS-based  computers . 

PLG  handles  the  problems  of  data  storage  and  graphics 
processing  speed  by  defining  several  special  data  structures 
and  some  unique  algorithms  to  manipulate  these  data 
structures .   One  data  structure  is  used  for  maintaining  the 
graphics  status  and  environment  This  data  structure  is 
never  accessed  directly  by  the  user,  but  is  manipulated 
indirectly  by  PLG  functions .   A  second  data  structure  is 
used  to  store  the  graphics  objects  defined  by  STRUCTURES. 
This  stores  actual  graphical  information  by  way  of  graphics 
primitives .   The  last  data  structure  is  for  maintaining  the 
display  list  to  refresh  the  screen.   It  stores  information 
concerning  which  STRUCTURES  and  transformations  are 
associated  with  each  view  and  which  views  are  currently 
active  (or  displayed)  on  the  screen.   As  with  the 
environment,  the  user  never  directly  interacts  with  these 
data  structures  but  indirectly  manipulates  them  through  PLG 
functions  making  any  implementation  transparent. 

The  development  of  algorithms  for  transformation 
application  and  inheritance  allowed  the  support  of  both  the 
geometrical  and  hierarchical  object  organization.   The  use 
of  a  stack  for  storing  and  retrieving  viewing  transformation 
matrices  helps  speed  the  inheritance  process  by  eliminating 
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calculations  of  inverse  matrices  and  unnecessary  extra 
matrix  multiplication. 

The  structure  traversal  algorithm,  used  to  update 
graphics  and  refresh  the  screen,  is  linear  (see  table  5.1) 
and  provides  a  depth-first  processing  of  nested  STRUCTURES. 
This  simulates  the  display  processor  which  might  be  present 
in  the  more  expensive  graphics  hardware  for  PCs. 


PLG  Performance  Results 
Table  5.1 

Vectors Time  to  Traverse  (in  seconds^ 

625  1.15 

1225  2.08 

2425  4.01 

3025  4.95 

4825  7.74 

6025  9.86 

9625  15.03 


PLG  offers  the  average  user  a  model  which  is  useful  on 
the  PC  by  defining  storage  methods  for  3-D  graphics  models 
which  allow  easier  manipulation  and  processing  of  graphics 
information.   In  addition,  a  number  of  algorithms  are 
offered  as  part  of  the  model  which  are  fast  and  efficient 
when  used  with  the  PLG  storage  methods  while  still 
maintaining  a  versatile  graphics  manipulation  model.   These 
algorithms  include  unique  methods  for  easy  implementation 
and  maintenance  of  dynamic  object  definitions  and  methods 
for  manipulation  of  these  objects,  as  well  as  methods  for 
dynamic  screen  updating. 

PLG  supplies  a  low-cost  alternative  for  sophisticated 
high-speed,  three-dimensional,  object-oriented  graphics  on 
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PCs.   It's  low  overhead  (approximately  15K  bytes)  and  fast 
processing  (almost  600  vectors  per  second  on  an  AT-class  PC) 
provide  the  average  user  with  a  useful  package.   An 
implementation  of  a  subset  of  PLG,  using  C  bindings,  is 
available  from  the  Computer  Graphics  Research  Lab  at  the 
University  of  Florida.  This  makes  PLG  easily  accessible  and 
well  within  the  reach  of  the  average  user  or  educational 
facility  which  wants  to  use  it  on  existing  or  new  equipment. 
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Future  Work 

Several  areas  of  research  pertaining  to  PLG  remain  to 
be  explored.   The  first  step  is  to  implement  the  complete 
system,  rather  than  the  current  subset  implementation. 
Components  which  remain  to  be  implemented,  after  further 
definition,  include   1)  the  text  output  primitive,  2)  the 
graphical  input  functions,  3)  the  ability  to  create  and  use 
programmer  supplied  color  tables,  and  4)  the  functions  for 
editing  STRUCTURES  and  STRUCTURE  elements .   Current  methods 
of  editing  STRUCTURES  involves  deleting  the  complete 
STRUCTURE  and  recreating  it. 

The  text  output  primitives  require  some  further  detail 
and  decisions  as  to  whether  geometric  text  capabilities 
should  be  added.   This  is  generally  determined  by  the 
available  hardware  and  must  be  considered. 

The  graphical  input  functions  need  to  be  expanded  to 
include  more  types  of  input  devices.   Another  possibility 
concerning  input  functions  would  be  the  definition  of  string 
devices  and  an  event  queue  which  would  allow  the  system  to 
determine  what,  if  any,  input  events  have  occurred. 

The  ability  to  create  and  use  different  color  tables 
needs  to  be  researched  as  well  as  the  definition  and  use  of 
color  systems  other  than  RGB. 

Another  area  of  interest  is  the  description  of 
additional  device  drivers,  such  as  800  by  600  and  1024  by 
768  pixel  resolutions.   The  structure  of  PLG  allows  the 
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extra  device  drivers  to  be  easily  integrated  by  using  a 
modular  driver-oriented  approach. 

An  important  consideration  for  PLG  is  the  investigation 
of  methods  for  directly  accessing  and  segmenting  the  video 
memory.   This  is  necessary  in  order  to  implement  video  page 
switching  which  is  used  for  smoother  animation.   The  price 
of  video  memory  has  been  decreasing   for  some  time,  and  low- 
cost  graphics  cards  are  now  available  with  as  much  as  512K 
bytes  of  video  memory  on  the  board.   Large  amounts  of  memory 
allow  additional  video  pages,  even  at  the  higher 
resolutions  (i.e.,  800  by  600  and  1024  by  768  pixels),  which 
are  not  currently  accessible  due  to  limitations  of  the 
current  driver  methods . 

One  subject  which  PLG  does  not  address  (but  GKS  3-D  and 
PHIGS  do)  is  archival  processing.   This  is  a  method  of 
storing  and  retrieving  images  external  to  the  PLG 
environment,  such  as  on  disk  or  other  forms  of  auxiliary 
storage.   Methods  for  adapting  PLG  for  archival  processing 
need  to  be  explored. 

The  addition  of  a  set  of  two-dimensional  graphics 
functions  and  the  extension  of  PLG  to  other  structured 
languages,  such  as  Ada  and  Pascal,  would  enhance  the 
software's  usefulness.   The  two-dimensional  functions  may  be 
created  by  simply  storing  a  zero  value  for  the  Z  coordinate 
and  then  internally  using  the  three-dimensional  functions. 
The  computing  overhead  costs  for  this  are  actually  quite 
inexpensive  and  very  desirable. 
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Finally,  a  topic  of  great  interest  is  the 
identification  of  PLG  functions  which  may  be  replaced  by 
future  hardware.   The  cost  of  graphics  hardware  is  beginning 
a  slow  decline [BR08 9] [PON89] ,  and  within  the  next  six  to  ten 
years  the  high-end  graphics  co-processor  boards  will  be 
priced  such  that  the  average  user  can  afford  them.   It  would 
be  quite  advantageous  to  design  a  graphics  co-processor 
board  which  implemented  PLCs  fast  algorithms  for  processing 
3-D  data. 


APPENDIX  A 

PLG  PROPOSED  FUNCTIONS 
All  functions  are  presented  in  the  following  form: 
FUNCTION  NAME  AND  CALLING  SEQUENCE 
ARGUMENTS 

DESCRIPTION  OF  ARGUMENTS 

DESCRIPTION  OF  FUNCTION  OPERATION  AND  RESULTS 

CONTROL  FUNCTIONS: 

graphics_close( ) 

no  arguments 

This  function  closes  the  PLG  graphics  system  and 
terminates  all  graphics  processing. 

graphics  open ( device ) 

int  device; 

device  -  is  a  manifest  constant  which  indicates 
the  graphics  output  device  (i.e.  CGA,  EGA,  etc.)  and  implies 
the  device's  capabilities  (resolution,  number  of  colors, 
etc . ) . 

This  function  initializes  the  PLG  graphics  system 
and  makes  all  PLG  functions  available. 


49 


50 


graphics  update_workstation( ) 

no  arguments 

This  function  generates  the  refresh  cycle  (i.e. 
structure  traversal).  All  structures  associated  with  active 
or  visible  views  are  redisplayed. 

OUTPUT  PRIMITIVE  FUNCTIONS: 


graphics_polygon3(  number,  xyz_points ,  width) 

int  number; 

float  xyz_points [ ] ; 

int  width; 

number  -  is  the  number  of  vertices  or  points  in 
the  polygon. 

xyz_points  -  is  an  array  of  floating  point  values 
which  are  the  X,  Y,  Z  coordinate  values  for  each  vertex  of 
the  polygon. 

width  -  is  the  number  of  array  elements  between 
subsequent  X  values . 

This  function  specifies  a  three-dimensional 
polygon  primitive  element  and  inserts  it  into  the  current 
open  structure  following  the  current  position  pointer. 
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graphics_polyline3( number,    xyz_points,    width) 

int  nvimber; 

float  xyz_points[ ] ; 

int  width; 

number  -  is  the  number  of  vertices  in  the 
polyline. 

xyz_points  -  is  an  array  of  floating  point  values 
which  are  the  X,  Y,  Z  coordinates  values  for  each  vertex  of 
the  polyline. 

width  -  is  the  number  of  array  elements  between 
subsequent  X  values . 

This  function  creates  a  three-dimensional  polyline 
element  and  inserts  it  into  the  current  open  structure 
following  the  current  position  pointer. 
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graphics  text (xyz_point,  length,  string) 

float  xyz_point [ 3 ] ; 
int  length; 
char  *  string; 

xyz_point  -  is  an  array  of  three  floating  point 
values  which  are  the  X,  Y,  Z  coordinate  of  the  text 
position. 

length  -  is  the  length  of  the  text  string  in 
characters . 

string  -  is  a  variable  length  character  string 
which  is  the  text  to  be  displayed. 

This  function  inserts  a  text  element  into  the 
current  open  structure  following  the  current  position 
pointer . 

ATTRIBUTE  SETTING  FUNCTIONS: 

graphics_set_f  ill_color  ( color  ) 

int  color; 

color  -  is  the  index  number  of  the  fill  color. 

This  function  sets  an  environment  variable  which 
determines  the  interior  color  of  any  polygons  created.  This 
color  is  utilized  only  if  the  polygon  interior  style  is 
solid. 
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graphics_set_interior_style  ( style ) 

int  style; 

style  -  is  the  interior  style  (l=hollow,   2=solid, 
3=pattern,  4=hatched) . 

This   function  sets  an  environment  variable  which 
determines  the  interior  style  of  any  polygons  created. 

graphics_set_line_color ( color ) 

int  color; 

color  -  is  the  index  number  of  the  line  color. 
This   function  sets  an  environment  variable  which 
determines  the  color  of  any  polylines  created. 

graphics_set_text_color ( color ) 

int  color; 

color  -  is  the  index  color  to  be  used  for  text. 
This   function  sets  an  environment  variable  which 
determines  the  color  of  any  text  created. 

graphics_set_text_f  ont  ( font ) 

int  font; 

font  -  is  the  index  number  of  the  font. 
This   function  sets  an  environment  variable  which 
determines  the  font  used  for  any  text  created. 
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graphics  set:  text  precision ( precision ) 

int  precision; 

precision  -  is  the  number  indicating  the  way  which 
text  is  treated. 

This  function  sets  an  environment  variable  which 
determines  the  precision  which  text  is  created  with 
(l=string,  2=character,  3=stroke) . 


WORKSTATION  SETTING  FUNCTIONS: 

graphic s  setcolorrepresentat ion ( number ,  colors ) 

int  number; 
float  colors [ ] ; 

number  -  is  the  number  of  colors  to  load, 
colors   -   is   an  array  of   three  times   number 
floating  point  values  which  are  the  color  table  values  to  be 
loaded   (0.0   <=  value  <=  1.0).   The  assumed  order  is   red, 
green,  blue. 

This  function  loads  red,  green,  blue  values  for  a 
given  color  table  into  the  graphics  environment. 
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graph±cs_set_view_character ( viewnumber ,  visibility, 

projection,  VRP) 

int  view_number; 
int  visibility; 
int  projection; 
float  VRP[3]; 

view_number  -  is  the  number  of  the  view  you  wish 
to  set  characteristics  for. 

visibility  -  is  a  flag  which  determines  whether 
the  view  is  posted  (visible)  or  not  (0=not  visible, 
l=visible) . 

projection  -  is  the  viewing  projection  for  the 
view  (0=parallel,  l=perspective) . 

VRP  -  is  an  array  of  three  floating  point  values 
which  contains  the  X,  Y,  Z  coordinate  of  the  view  reference 
point  (i.e.  the  user's  point  of  view). 

This  function  sets  the  basic  characteristics  of  a 
view,  including  whether  or  not  the  view  is  visible.  This 
must  be  called  initially  for  all  views  because  by  default 
all  views  created  are  not  active  (i.e.  not  visible). 
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STRUCTURE  OPERATION  FUNCTIONS: 

graphics_close_structure( ) 

no  arguments 

This  function  sets  the  current  open  structure  to  a 
closed  state  (i.e.  no  more  elements  may  be  added  at  this 
time) . 

graphics_delete_all_structures ( ) 

no  arguments 

This  function  deletes  all  existing  structures  from 
the  system. 

graphic s_delete element ( ) 

no  arguments 

This  function  deletes  the  element  indicated  by  the 
current  element  pointer  from  the  current  open  structure. 

graphics_delete_structure  (  structureuumber  ) 
int  structure_number; 

structure_number  -  is  the  number  of  the  structure 
to  be  deleted. 

This  function  is  used  to  delete  the  contents  of 
the  specified  structure.  This  is  effectively  the  same  as 
emptying  the  structure. 
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graphic  s_set_element_po  inter  (  element: ) 

int  element; 

element  -  is  the  element  position  number. 

This  function  sets  the  current  element  pointer  to 
a  particular  element  in  the  current  open  structure.  If  the 
value  of  element  is  less  than  one,  the  pointer  is  set  to  the 
first  element.  If  the  value  of  element  is  greater  than  the 
number  of  elements  in  the  structure,  the  pointer  is  set  to 
the  last  element. 

graphic s_execute_s tructure  (  structure  nunber  ) 
int  structure_number; 

structure_number  -  is  the  number  of  the  structure 
to  invoke . 

This  function  inserts  an  execute  structure  element 
into  the  current  open  structure.  Traversal  of  the  structure 
in  which  the  execute  structure  element  exists  causes 
invocation  of  the  target  structure  as  soon  as  the  execute 
structure  element  is  encountered. 

graphics_open_structure ( s true turenumber ) 

int  structure_number; 

structure_number  -  is  the  number  of  the  structure 
to  create  or  open. 

This  function  opens  a  structure.  If  the  specified 
structure  doesn't  exist,  then  it  is  created.  The  element 
pointer  is  positioned  at  the  last  element  of  the  structure. 
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INPUT  FUNCTIONS: 

graphics_initialize_input_device ( device ) 

int  device; 

device  -  is  the  index  number  of  the  input  device 
(0=mouse,  1= joystick,  >l=generalized  input  device  via  serial 
port) . 

This  function  identifies  the  input  device  and 
loads  its  driver,  if  necessary. 

graphic s_get_xyz ( device,  xyz  point,  button) 

int  device; 

float  xyz_point[3] ; 

int  button; 

device  -  is  the  index  number  of  the  input  device. 
xyz_point   -  is  an  array  of  three   floating  point 
values  in  which  the  X,  Y,  Z  coordinate  of  the  input  point  is 
returned . 

button  -  is  the  number  of  the  button  indicated  on 
the  input  device. 

This  function  searches  for  graphic  input  from 
device#  device  and  returns  the  point  in  xyz_point  and  the 
value  of  the  button  pushed  in  button. 
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DISPLAY   FUNCTIONS: 

graphics_assoc_root_with_view(  viewnumber  g 

structuxe_nuinber  ) 

int  view_number; 

int  structure_number; 

view_number  -  is  the  index  number  of  the  view  to 
be  attached  to. 

structure_number  -  the  index  number  of  the 
structure  to  be  associated  with  view  view_number. 

This  function  associates  structure 
structure_number  with  view  view_number,  so  that  structure 
structure_number  is  included  in  the  traversal  list  for  that 
view.  If  the  structure  doesn't  exist  an  error  flag  is 
raised.  If  the  structure  is  already  associated,  then  no  new 
action  is  taken.  If  the  view  doesn't  exist,  then  it  is 
automatically  created. 
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graphic  sdisassoc  root_£ram_view( view _number , 

structure  nuaber ) 
int  view_number ; 
int  structure_number; 

view_nnmber  -  is  the  index  number  of  the  view  to 
be  affected. 

structure_number  -  is  the  structure  number  to  be 
removed . 

This  function  allows  structure  structure_number  to 
be  removed  from  the  traversal  list  of  view  view_number.  The 
structure  is  removed  from  the  structure  during  the  next 
structure  traversal. 

TRANSFORMATION  FUNCTIONS: 

graphics_set _model_x£ orm3 (matrix ,  type ) 

float  matrix[4] [4] ; 
int  type; 

matrix  -  is  a  4  by  4  array  of  floating  point 
values  which  defines  the  modeling  transformation  to  be 
applied  locally. 

type  -  is  the  composition  type  (0=replace/ 
l=preconcatenate,  2=postconcatenate) . 

This  function  inserts  a  three-dimensional 
modeling  transformation  element  into  the  current  open 
structure  following  the  current  position  pointer.  During 
traversal,  this  element  modifies  the  current  local 
transformation  as  specified  by  the  composition  type. 
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graphic  s_set_view  mapping  (  viewnumber  ,   window, 

viewport) 

int  view_number ; 
float  window [ 6 ] ; 
float  viewport [6]; 

view_number  -  is  the  index  number  of  the  view, 
window  -  is  an  array  of  six  floating  point  values 
which  define  the  window  limits  in  world  coordinates   (XMIN, 
XMAX,  YMIN,  YMAX,  ZMIN,  ZMAX) . 

viewport  -  is  an  array  of  six  floating  point 
values  which  define  the  viewport  limits  in  normalized  device 
(0.0  <=  value  <=  1.0)  coordinates  (XMIN,  XMAX,  YMIN,  YMAX, 
ZMIN,  ZMAX). 

graphics_set_view_xf orm3 ( matrix ,  type ) 

float  matrix[4] [4] ; 
int  type; 

matrix  -  is  a  4  by  4  array  of  floating  point 
values  which  define  the  modeling  transformation  to  be 
applied  globally. 

type  -  is  the  composition  type  (0=replace, 
l=preconcatenate,  2=postconcatenate) . 

This  function  sets  up  a  global  transformation 
which  is  applied  to  all  structures  of  the  specified  view  at 
traversal  time. 
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UTILITY  AND  MISCELLANEOUS  FUNCTIONS: 

graphics  concatenate  matrix (matrixA,  matrixB,  matrixC) 

float  matrixA[4] [4] ; 
float  matrixB[4] [4] ; 
float  matrixC[4] [4] ; 

matrixA,  matrixB,  matrixC  -  are  4  by  4  arrays  of 
floating  point  values  which  contain  three-dimensional 
transformations . 

This  function  multiplies  matrixA  times  matrixB  and 
returns  the  result  in  matrixC. 

graphics_rotate_X( angle,  matrix) 

float  angle; 

float  matrix[4] [4] ; 

angle  -  is  the  rotation  angle  in  radians . 
matrix  -   is   a  4  by  4  array  of   floating  point 
values  which  represents  a  three-dimensional   transformation 
matrix. 

This  function  calculates  a  rotation  transformation 
around  the  X-axis  using  a  given  angle  of  rotation.  The 
transformation  is  returned  in  matrix. 
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graphic s_rotate_Y( angle,  matrix) 

float  angle; 

float  matrix[4] [4] ; 

angle  -  is  the  rotation  angle  in  radians . 
matrix  -   is   a  4  by  4  array  of   floating  point 
values  which  represents  a  three-dimensional   transformation 
matrix. 

This  function  calculates  a  rotation  transformation 
around  the  Y-axis  using  a  given  angle  of  rotation.  The 
transformation  is  returned  in  matrix. 

graphic s_rotate_Z ( angle ,  matrix ) 

float  angle; 

float  matrix[4] [4] ; 

angle  -  is  the  rotation  angle  in  radians . 
matrix  -   is   a  4  by  4  array  of   floating  point 
values  which  represents  a  three-dimensional   transformation 
matrix. 

This  function  calculates  a  rotation  transformation 
around  the  Z-axis  using  a  given  angle  of  rotation.  The 
transformation  is  returned  in  matrix. 
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graphics_scale3 ( scale ,  matrix ) 

float  scale[3]; 
float  matrix[4] [4] ; 

scale  -  is  an  array  of  three  floating  point  values 
which  represent  the  scale  factors  in  the  X,  Y,  Z  directions, 
matrix  -   is   a  4  by  4  array  of   floating  point 
values  representing  a  transformation  matrix. 

This  function  calculates  a  three-dimensional 
scaling  transformation  using  a  given  three-dimensional 
vector  containing  X,  Y,  and  Z  scale  factors.  The 
transformation  is  returned  in  matrix. 

graphics _translate3 ( vector ,  ■at.ri x ) 

float  vector[3]; 
float  matrix[4] [4] ; 

vector  -  is  an  array  of  three  floating  point 
values  containing  X,  Y,  and  Z  translation  components. 

matrix  -  is  a  4  by  4  array  of  floating  point 
values  containing  a  transformation  matrix. 

This  function  calculates  a  three-dimensional 
translation  transformation  using  a  given  three-dimensional 
translation  vector  containing  X,  Y,  and  Z  translation 
components.   The  transformation  is  returned  in  matrix. 
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graphics  xfonnjpoint 3 (point,  matrix,  result) 

float  point [3] ; 
float  matrix[4] [4] ; 
float  result[3]; 

point  -  is  an  array  of  three  floating  point  values 
which  represent  X,  Y,  and  Z  coordinates  of  a  point. 

matrix  -  is  a  4  by  4  array  of  floating  point 
values  which  represents  a  transformation. 

result  -  is  an  array  of  three  floating  point 
values  which  represents  the  X,  Y,  and  Z  coordinate  of  a 
point . 

This  function  transforms  a  three-dimensional  point 
using  a  specified  three-dimensional  transformation  matrix. 
The  result  of  multiplying  the  given  point  by  the 
transformation  matrix  is  returned  in  result. 

Other   functions   include  inguiry  and  error  handling 
functions  as  needed. 


APPENDIX  B 
SAMPLE  PROGRAMS 


Program  1 


#include  "phigs.c" 

/*  Program  1 
This  program  draws  a  three-dimensional  solid  cube  on  the 
screen  and  rotates  it  in  real  time  applying  back  face 
removal  to  insure  that  the  proper  faces  are  drawn  */ 

int  count; 

/*  Data  points  for  cube  faces  */ 

float  PTS[24]  ={-0.5,  0.5,  0.5,  0.5,  0.5,  0.5, 
-0.5,  -0.5,  0.5,  0.5,  -0.5,  0.5, 
-0.5,  0.5,  -0.5,  0.5,  0.5,  -0.5, 
-0.5,  -0.5,  -0.5,  0.5,  -0.5,  -0.5   }  ; 

float  rotation; 

/*  Point  indices  for  cube  faces  */ 

int  FACES[6][4]  =  {   {1,  2,  4,  3},  {2,  6,  8,  4}, 

{6,  5,  7,  8},  {5,  1,  3,  7}, 
{5,  6,  2,  1},  {3,  4,  8,  7}   }; 

float  vrp[3]  =  {  0.0,  0.0,  5.0};  /*  view  reference  point  */ 
float  window[6]  =  {-2.0,  2.0,  -2.0,  2.0,  -2.0,  2.0}; 
float  viewport [6]  =  {  0.1,  0.9,  0.0,  1.0,  0.0,  1.0  }; 

void  drawfaces( rotation) 
float  rotation; 

{ 
/*  This  function  constructs  the  cube  faces  and  draws 

them  */ 
int  h,  i,  j,  k,  1,  m; 
float  a_face[12]; 
float  c; 

float  MATA[4][4],  MATB[4][4],  MATC[4][4]; 
float  test [3] ; 

/*  Calculate  transformation  matrices  */ 
graphics_rotate_y( rotation,  MATA) ; 
graphics_rotate_x( -1.17*3. 1415926,  MATB) ; 
graphics_concatenate_matrix(MATA,  MATB,  MATC); 
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/*  Construct  a  cube  face  */ 
for  (h=0;  h<=5;  h++) 

{ 
j=0; 
for  (k=0;  k<=3;  k++) 

{ 

i  =  (FACES[h][k]  -  1)  *  3; 

for  (1=0;  1<=2;  1++) 
{ 
a_face[j]  =  PTS[i+l]; 

} 
graphics_set_fill_color(h+l) ;  /*  set  fill  color  */ 

for  (1=0;  1<=11;  l+=3) 

{ 

test[0]  =  a_face[l];  test[l]  =  a_face[l+l]; 

test [2]  =  a_face[l+2]; 

graphic s_apply_pt_to_matrix ( test ,  MATC , test ) ; 

a_face[l]  =  test[0];  a_face[l+l]  =  test[l]; 

a_face[l+2]  =  test[2]; 
} 

/*  apply  backface  removal  */ 

c  =  a_face[0]  *  (a_face[4]  -  a_face[7]  )  + 

a_face[3]  *  (a_face[7]  -  a_face[l]  )  + 

a_face[6]  *  (a_face[l]  -  a_face[4]  )  ; 

if  (c  <=  0.0) 

graphics_polygon3 ( 4 ,    a_f ace ,  3 ) ; 


main( ) 

{ 
int  count; 

graphics_open(_ERESCOLOR) ; 
graphics_set_view_character( 1,  1,  0,  vrp) ; 

graphic s_set_view_mapping( 1,  window,  viewport); 
graphics_open_structure( 1) ; 
graphics_close_structure( ) ; 
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/*  Create  and  draw  cube  63  times  */ 
for  (count=l;  count  <=63;  count ++) 

{ 
graphics_delete_structure( 1) ; 
graphics_open_structure ( 1 ) ; 
graphic s_set_inter ior_s tyle( 1) ;  /*  solid  */ 
rotation  =  (3.14*2.0/30.0)  *  (float)  count; 
drawfaces(  rotation); 
graphics_close_structure( ) ; 

graphic s_assoc_root_with_view( 1 ,  1 ) ; 
graphic s_update_works tat ion ( ) ; 
} 

while  (  ikbhit()  );  /*  Pause  */ 
graphic s_c lose ( ) ; 
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Program  2 

finclude  "phigs.c" 

/*  Program  2 

This  program  creates  and  rotates  a  simple  3-D  wire-frame 
cube  in  real  time  by  changing  only  the  viewers  reference 
point  */ 

main  ( ) 

{ 
float  rp[3],  pts[12]; 
float  matrix[4] [4] ; 
int  i; 
float  angle; 

graphic s_open(_ERESCOLOR) ; 

graphics_open_structure(l) ;  /*  Create  polygons  for  cube  */ 

pts[0]  =  -0.5;   pts[l]  =  -0.5;   pts[3]  =  -0.5; 
pts[4]  =   0.5;   pts[6]  =   0.5;   pts[7]  =   0.5; 
pts [9]  =   0.5;   pts [10]  =  -0.5; 
for  (i=2;  i<12;  i+=3) 
pts[i]  =0.5; 

graphic s_polygon3 (4,  pts,  3); 

for  (i=2;  i<12;  i+=3) 
pts[i]  =  -0.5; 

graphics_polygon3(4,  pts,  3); 

pts[0]  =  -0.5;   pts[l]  =  0.5;   pts [2]  =  0.5; 
pts [9]  =   0.5;   pts [10]=  0.5;   pts [11]=  0.5; 

graphic s_polygon3 (4,  pts,  3); 

for  (i=l;  i<12;  i+=3) 
pts[i]  =  -0.5; 

graphic s_polygon3 (4,  pts,  3); 

graphics_close_structure( ) ; 

graphic s_assoc_root_with_view( 1 ,  1 ) ; 

rp[0]  =  2.0;    rp[l]  =  0.0;   rp[2]  =  0.3; 
graphics_set_view_character( 1,  1,  0,  rp) ; 

graphic s_update_works tat ion ( ) ; 

angle  =  6.28  /  60.0; 
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graphics_rotate_z( angle,  matrix) ; 

for  (i=0;   i<60;   i++)      /*  Rotate  cube  60  times  */ 

{ 

float  tempx,  tempy; 

graphic s_set_view_charac ter ( 1,  1,  0,  rp) ; 

graphic s_update_works tat ion ( ) ; 

graphics_apply_pt_to_matrix(rp,  matrix,  rp) ; 
} 

while  (  !kbhit()  )   ;  /*  Pause  */ 
graphics_close( ) ; 
} 
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Program  3 

#include  "phigs.c" 

/*  Program  3 

This  program  reads  in  data  from  a  disk  file  and  produces 
an  object  (in  this  case  a  wire-frame  teapot)  from  it.  */ 

main  ( ) 

{ 
float  pts[21],  win[6],  rp[3]; 
FILE  *  fp; 
int  dummy,  i,  j; 

fp  =  f open ( "teapot.dat" ,  "r"); 
graphics_open(_VRES16C0L0R) ; 

graphics_open_structure( 1) ; 

for  (i=0;  i<448;  i++) 

{ 

fscanf(fp,  "%d",  &dummy) ; 
for  (j=0;  j<21;  j  +=  3) 

{ 
fscanf(fp,  "%f  %f  %f",  &pts[j],  &pts[j+l],  &pts[j+2]  ); 

} 

graphics_polyline3(7,  pts,  3); 

} 

graphics_close_structure( ) ; 

graphics_assoc_root_with_view( 1, 1) ; 

win[0]  =  -4.0;  win[l]  =  4.0;   win[2]  =  -1.0;  win[3]  =4.0; 
win[4]  =  -4.0;  win[5]  =4.0; 

graphic s_set_view_mapping( 1,  win,  graphics .viewport) ; 

rp[0]  =  0.0;   rp[l]  =  5.0;   rp[2]  =  0.0; 
graphics_set_view_character( 1,  1,  0,  rp) ; 

graphic s_update_works tat ion ( ) ; 

while  (  !kbhit()  )   ; 
graphics_close( ) ; 

fclose(fp) ; 

} 


72 


Program  4 

#include  "phigs.c" 
#include  <dos.h> 

/*  Program  4 

This  program  creates  a  3-D  surface.  This  program  was 
generated  to  produce  performance  results  listed  in 
the  conclusion.   */ 

float  VRP[3]  =  {40.0,  10.0,  10.0}; 

float  window[6]  =  {-15.0,  15.0,  -15.0,  15.0,  -15.0,15.0}; 

union  REGS  inreg,  outregl,  outreg2; 

float  fnz(  float  x,  float  y) 

{ 

float  w,  e,  c; 

w  =  x*x  +  y*y; 

e  =  exp(  (double)  (-0.04  *  w)  ); 

c  =  cos(  (double)  (  0.15  *  w)  ); 

return (  14.0  *  e  *  c); 
} 

main( ) 

{ 
float  far  table[3*121] ; 
float  x,  y; 
int  i,  j; 
inreg. h. ah  =  0x2c; 

graphic s_open(_VRES 16 COLOR) ; 
graphics_open_structure ( 1 ) ; 

for  (y=12.0,  i=0;  y>=-12.0;  y-=1.0,  i++) 

{ 
for  (x=-12.0,  j=0;  x<=12.0;  x+=0.2,  j+=3) 

{ 
table[j]  =  x;  table[j+l]  =  y; 
tablet j+2]  =  fnz(x,y); 

} 
graphics_polyline3( 121,  table,  3); 

} 
graphics_close_structure( ) ; 

graphics_set_view_character( 1,  1,  0,  VRP); 

graphic s_set_view_mapping( 1,  window,  graphics .viewport) ; 

graphic s_assoc_root_with_view( 1 ,  1 ) ; 

intdos ( & inreg,  &outregl ) ; 
graphics_update_workstation( ) ; 

intdos ( &  inreg ,  &outreg2 ) ; 

while  (  I kbhit ( )  )  ; 
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graphic s_c lose ( ) ; 

printf ( "%d:%d:%d.%d  \n" ,  outregl .h.ch,  outregl. h.cl, 

outregl.h.dh,  outregl. h. dl ) ; 

printf ( "%d:%d:%d.%d  \n" ,  outreg2 .h.ch,  outreg2 .h.cl, 

outreg2 .h.dh,  outreg2.h.dl) ; 


} 
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